The present invention relates generally to the field of computer software, and more particularly to a mechanism for automatic synchronization of scripting variables in a tag extension facility suitable for JAVASERVER™ Pages.
The JAVA™ programming language is expressly designed for use in the distributed environment of the Internet. It is designed to have the “look and feel” of the C++ programming language, but it is simpler to use than C++ and enforces an object-oriented programming model. The JAVA™ programming language can be used to create complete applications that can run on a single computer or be distributed among servers and clients in a network. The JAVA™ programming language can also be used to build a small application module or applet for use as part of a webpage. Applets make it possible for a Web page user to interact with the page. JAVASERVER™ Pages is the JAVA™ programming language platform technology (hereinafter JAVA platform) for building applications containing dynamic Web content such as HTML, DHTML, XHTML, and XML. A JAVASERVER™ Page (JSP) is a text-based document that describes how to process a request to create a response. The description inter-mixes template data with some dynamic actions, taking advantage of the capabilities of the JAVA™ programming language platform. The template data is commonly fragments of a structured document (HTML, DHTML, XHTML or XML), and the dynamic actions can be described with scripting elements and/or server-side actiontags.
A simple example of a JSP page is shown in FIG. 2. The example shows the response page, which is intended to be a short list of the day of the month and year, at the moment the request is received by the server. The page itself contains some fixed template text, and JSP elements that are shown underlined in the figure. The underlined actions are executed on the server side. When a client makes a request, such as an HTTP request, a request object requests a response from the JAVASERVER™ container object. The first element creates a JAVA™ Bean component named clock, of type calendar.jspCalendar. The next two elements use the JAVA Bean component to display some of its properties (i.e. month and year). The output is sent to a response object which sends a response back to the client.
A JSP page is executed by a JSP container, which is installed on a Web server, or on a Web enabled application server. The JSP container delivers requests from a client to a JSP page and responses from the JSP page to the client. JSP pages may be implemented using a JSP translation or compilation phase that is performed only once, followed by a request processing phase that is performed once per request. The translation phase creates a JSP page implementation class that implements a servlet interface.
Typically, a JSP page contains declarations, fixed template data, action instances that may be nested, and scripting elements. When a request is delivered to a JSP page, all these components are used to create a response object that is then returned to the client. As with standard Web pages, JSP pages may contain “tags.” A tag is a textual element within a document that provides instructions for formatting or other actions. For example, World Wide Web documents are set up using HTML (Hyper-Text Mark-up Language) tags which serve various functions such as controlling the styling of text and placement of graphic elements, and also providing links to interactive programs and scripts.
In standard implementations, a JSP page is translated into JAVA™ programming language code (hereinafter JAVA™ code) that runs on a server. The transformation from the JSP page into JAVA™ code is done once, when the page is first accessed. The JAVA™ code running on the server is activated when a request is received. In order to create a response object, certain data is passed verbatim to the response, and some actions are executed on the server side. Some of these actions are explicitly spelled out in the JSP page, and other actions are described by the semantics of the text. Thus, there are three types of code: verbatim code, scripting code from the JSP page, and code which has to be defined by the tag library. As used herein, “tags” in the JSP context will be referred to as “actions.”
Ideally, a tag mechanism employed in a JSP page system would allow for actions to be defined in standard libraries. This would allow third parties to provide new actions as part of their JSP authoring tools. For example, as shown in FIG. 3, a JSP page author may use a JSP specification-compliant authoring tool to create a Web page. The vendor of the authoring tool can provide new actions via a JSP tag library, such as a tag library that supports chat room functionality. The page can then be deployed into any JSP-compliant container, such as a Web browser. The Web browser uses the same tag library information in order to run the Web page, including the desired chat room functions.
In other words, if a standard JSP tag mechanism is properly defined, vendors of tag libraries can use the standard specification to create tag libraries that are compliant with the JSP environment. Also, vendors of authoring tools can create authoring tools (and scripting languages) compliant with the specification, and vendors of Web browsers can create JSP compliant Web browsers. A Web page author can then choose the best tag library and the best authoring tool available for creating the desired Web pages. Two different Web browsers may support scripting in a completely different manner, but the same tag libraries must be supported by both in order to run the Web page. In a JSP page, there are objects that are created at execution time, which can be associated with variables in the scripting language. The tag extensions can be invoked from the main JSP page and may update the objects, or create new ones. When creating a new object, the tag extension may need to provide the new object to the JSP page, and associate the object with a scripting variable. However, the tag extensions and the scripting page may be defined in different languages. Thus, there is a need to define a mechanism such that the scripting variables can be passed between the JSP container and the tag extension mechanism and updated automatically (i.e. the variables can be synchronized).
Certain prior extension mechanisms rely on explicit manipulation of the variable to object mapping (i.e. a context). This context is available to both the extension mechanism and to the scripting elements in the JSP page, either directly in the language or through explicit method calls. Other extension mechanisms are mono-lingual and assume that the context is known to both the extension mechanism and the scripting elements in the JSP page. Both approaches are too restrictive, however. Preferably, an implementation would provide greater flexibility for allowing different, compatible scripting languages to work with the tag extension mechanism.